Jolt: Converting bytecode to C Continuing on
It would be neat if there could be a coexisting alternative to the current class API, but that seems to be a larger problem than just writing a VM that can reuse the remainder of the environment that is presently available. What I've got this far fits into this picture as a way to increase the performance of any portions of the Java environment written in Java (with adequate hooks into a VM ofcourse)
Thats about it :-) Please mail me if you are interested. The rest of this are random ramblings.
For one thing, converting bytecode to C is simpler, and potentially easier to port on low priority (for Sun) platforms. For another, it leverages off existing code generators/optimizers. Dynamically compiled code (which ofcourse would not be reasonable to implement by running a full blown compiler in the middle :-) does have its place, but there is room for a C based translation especially when it comes to one shot compiles -- like say converting the awt or the compiler code into C and then to native.
Sure, if only so an alternate exists or coexists. Even if the source from Sun continues to be freely available (under a license, which is what I've been led to believe) an alternate implementation is still a good thing for a few more reasons. First, there needs to be a VM implementation that is more widely understood and documented than what exists today. Secondly, the source available now typically lags development work by a bit. It is but natural, but then hard to play catch up if you aren't part of the circle knowledgeable about the directions in which the development proceeds.
There were/are several discussions on the newsgroup about this, and the consensus from the Sun developers seemed that java is unsuitable to write a fast bytecode interpreter. Dunno. I don't feel strongly one way or another. Setting aside the cute-sie notion of self interpretation, I could think of only two reasons to want to write the VM in Java. One, it is probably more portable to write in Java, convert to bytecode, translate to C and then compile than write C in the first place. Adding pointer arithmetic checking in some parts of the VM itself wouldn't be such a bad idea. The second is the minor serendipitous effect that the VM and all code would use the same set of base classes to hook into the underlying system. For instance the VM now implements file access in C and in the File.java class native implementations. The con is what the Sun team seems to suggest -- it would lead to a slow VM, and the portability gains are not that much.
Its a fait accompli right now in Suns VM :-) Does it look like it might take the route of the x86 architecture, with backward compatibility in mind? For a while, I was thinking along the notions of using 3 address code instead of, or augmenting stack based code. This type of opcode will satisfy all the type safety requirements, and allow for elimination of stack operations. So one can portably execute a bytecode that allows for faster interpretation. But having gone the current route, I can't emphasize enough what others have already iterated before -- optimizing method invocations and field accesses in the VM takes priority over dickering with converting expression trees into stack code or 3 address code.
KB Sriram
Comments, bug reports: kbs@sbktech.org
Revised: Sat May 25 10:35:24 1996
URL: http://www.sbktech.org/ideas.html